Den första uppgiften är att bestämma vilken processmodell som ska användas i TopBike-projektet. Börja med att läsa igenom beskrivningen ordentligt (separat dokument).
Svara på följande frågor:
Vilka är de två största tekniska riskerna med projektet?
Vilka är de två största riskerna med projektet om man väljer en rörlig metod?
Vilken är de två största riskerna med projektet om man väljer en plandriven metod?
På bas av ett poldiagram (eller radardiagram) som det i artikeln, argumentera för huruvida en plandriven eller en rörlig metod bör väljas.
Vilka tillägg bör man göra till processen för att hantera de tekniska riskerna i fråga 1?
Vilka tillägg bör man göra till processen för att hantera de rörliga/plandrivna riskerna i fråga 2/3? (Om du valde en rörlig metod, bör du hantera de rörliga riskerna. Om du valde en plandriven metod, bör du hantera de plandrivna riskerna.)
Svar:
1)
En av de största och mest kritiska tekniska riskerna med detta projekt är att systemet blir instabilt och kan krascha. Detta kan ha väldigt stora konsekvenser för företaget som i princip flyttar hela sin försäljning till systemet. Eftersom företaget använder sig av sin egen server för att hålla systemet ger detta också att SMEsonline:s egen server kommer att belastas av detta, och redundans måste finnas för att företaget ska kunna uppehålla sin aktivitet. En annan sak som inte direkt hör till den tekniska biten av riskerna i detta system är att kommunikationen till systemet måste vara stabil eftersom man inte har någonting på hårdvarumaskinen i butiken.
En annan relativt stor risk med detta projekt är SMEsonlines egna anställda som nyligen har blivit anställda. De personer som arbetar med projektet kan vara relativt ovana med den arbetsmetodik som finns på SMEsonline och därtill kan de vara ovana programmerare som inte har erfarenhet av den här typen av projekt som baserar sig på E-handel. Detta kan leda till felaktiga beslut i initieringsstadiet och kan därmed leda till problem i ett senare skede av projektet. Därtill kan arkitekturen på systemet bli instabil på grund av ovana vilket i sin tur kan leda tillbaka till den första risken med projektet.
2)
Risker med rörliga metoder uppkommer troligen när det gäller kundkontakten som är en vital del av de rörliga metodernas arbetssätt. Detta kan vara ett problem om man har svårt att tala kundens språk" ifråga om tekniska detaljer, speciellt ifall kunden i detta fall inte är införstådd i nätbaserade system sen tidigare. Dessutom kan det uppkomma problem att komma överens om när projektet verkligen är slutfört och vilka detaljer som skall ingå och vilka som är tillägg utöver det ursprungliga kontraktet, eftersom kunden är ovan med att definiiera mjukvaruspecifikationer.
Ett annat problem som kan uppkomma i projektet är att tiden för projektet är väldigt kort och därför blir det relativt kritiskt att man snabbt kommer fram med en bra lösning på problemet. I efterhand kan det vara svårt att ändra på denna lösning och göra en helt ny lösning eftersom man helt enkelt inte har tid att göra detta. Att arbeta med prototyper är en sak som tyvärr inte kan användas i detta projektet, fastän det troligen vore det bästa sättet att få kundinteraktion.
3)
Kunden är inte säker på vad han verkligen vill ha och hur systemet borde se ut för att vara användarvänligt, detta skulle i så fall kunna leda till problem i slutändan av projektet om produkten inte visar sig vara tillräckligt användarvänlig, då detta är en av de mest kritiska delarna i projektet för att alla inom TopBike skall acceptera att övergå till detta system. .
Programmerarna på SMEsonline är så pass införstådda i rörliga arbetsmetoder att de inte följer arbetsordningen för plandriven programmering, och därmed skapar problem i projektet. Eftersom arbetsstyrkan är liten och de anställda på företaget är unga nyutbildade programmerare har man troligen använt sig i huvudsak av rörliga metoder i programmeringsprojekt. Detta gör de ovana med att använda plandrivna metoder att det orsakar ännu mera problem att inte använda rörliga metoder.
4)
Om man utgående från ett poldiagram undersöker huruvida det är klokt att använda rörliga metoder så kan man se vissa trender. Om man utgående från den fempoliga diagramsmodellen undersöker detta projekt och börjar med att undersöka hur pass kritiskt systemet bör vara så har det vissa kritiska delar som måste tas i beaktande. Bland annat kommer man att behöva ha redundans på programmet som följd av reglementen angående datasäkerhet. Utöver det kan man anse att så gott som hela affärsverksamheten flyttas över till detta system, så detta leder till att systemet måste vara stabilt.
Angånde polen om storleken på programmeringsstyrkan så kommer den inte att vara särskilt hög i detta projekt som till sin storlek är ganska litet, och detta gör att programmerarna kan använda sig av rörliga metoder.
Dynamiken i projektet kan också anses vara relativt hög, och behovet av att utöka och ändra om systemet kan anses vara befogat i och med att systemet kommer att användas också av kunder vilket gör det viktigt att utseendet är enkelt och överskådligt, men på samma gång fräscht och tilltalande.
Personalen som kommer att använda systemet kommer troligen att vara relativt liten och förhoppningsvis kommer det i programmeringsteamet att finnas relativt stor del av erfarna programmerare som är vana med rörliga metoder och att ändra krav efter behov. Detta är också en delorsak till att det vore mera ändamålsenligt att använda rörliga metoder.
Kulturen på företaget SMEsonline kan anses vara relativt nymodig och ungdomlig, och detta skulle också innebära det lättare att implementera rörliga metoder framom plandrivna metoder i detta projekt.
Med polardiagrammets hjälp har vår grupp kommit fram till att det mest effektiva sättet att arbeta i detta projekt är med hjälp av rörliga metoder. Dock har vårt system vissa kritiska funktioner som man måste vara noggrann med och dessa funktioner skulle man kanske kunna ordna med någon slags form av plandrivna metoder för att säkerställa att funktionerna verkligen fungerar och håller en hög kvalitet.
5)
Det som är viktigt är att systemet är stabilt och därför måste man lära sig om lagstiftningen kring det som behövs för att hålla systemet lagligt. En annan sak som är viktigt med projektet är att man relativt snabbt kommer ut på marknaden med sitt system innan andra skapar konkurrerande system. Därför bör projektet ha en klar rörlig metodik som man arbetar med för att snabbt komma fram med fungerande programvara som kan visa kunden hur det slutgiltiga systemet kommer att se ut.
För att kunna säkerställa att projektet hålls "på rätt köl" borde man i projektgruppen ha med åtminstone en erfaren programmerare som håller koll på hur systemet utvecklas. Annars kan man lätt hamna i en situation att systemet kommer in i ett dödläge där man inte kommer framåt mera utan måste börja om på nytt med att designa systemet och det vore förödande för tidtabellen på projektet.
6)
För att undvika problem med att kunden inte vet vad han behöver bör man i ett tidigt skede underrätta honom om företagets arbetssätt och göra honom uppmärksam på hur han kan styra systemet och definiera det. Detta gör att kunden får mera insyn i systemet och förstår bättre vad det är som han behöver. En annan sak som man kan göra för att ytterligare få information om huruvida det slutgiltiga systemet borde se ut skulle kunna vara att fråga kunden om exempel på användarvänliga system för att därigenom lyckas luska ut vad kunden behöver.
Därtill måste man ständigt hålla klart för sig vilken funktionalitet som förväntas i det slutgiltiga systemet så man har ett mål med projektet och kan avsluta det i tid. Annars finns det en överhängande risk att projektets slutliga version blir "hängande" i luften när tiden tar slut i projektet.
Svara på följande frågor:
Svar:
1)
En av de största och mest kritiska tekniska riskerna med detta projekt är att systemet blir instabilt och kan krascha. Detta kan ha väldigt stora konsekvenser för företaget som i princip flyttar hela sin försäljning till systemet. Eftersom företaget använder sig av sin egen server för att hålla systemet ger detta också att SMEsonline:s egen server kommer att belastas av detta, och redundans måste finnas för att företaget ska kunna uppehålla sin aktivitet. En annan sak som inte direkt hör till den tekniska biten av riskerna i detta system är att kommunikationen till systemet måste vara stabil eftersom man inte har någonting på hårdvarumaskinen i butiken.
En annan relativt stor risk med detta projekt är SMEsonlines egna anställda som nyligen har blivit anställda. De personer som arbetar med projektet kan vara relativt ovana med den arbetsmetodik som finns på SMEsonline och därtill kan de vara ovana programmerare som inte har erfarenhet av den här typen av projekt som baserar sig på E-handel. Detta kan leda till felaktiga beslut i initieringsstadiet och kan därmed leda till problem i ett senare skede av projektet. Därtill kan arkitekturen på systemet bli instabil på grund av ovana vilket i sin tur kan leda tillbaka till den första risken med projektet.
2)
Risker med rörliga metoder uppkommer troligen när det gäller kundkontakten som är en vital del av de rörliga metodernas arbetssätt. Detta kan vara ett problem om man har svårt att tala kundens språk" ifråga om tekniska detaljer, speciellt ifall kunden i detta fall inte är införstådd i nätbaserade system sen tidigare. Dessutom kan det uppkomma problem att komma överens om när projektet verkligen är slutfört och vilka detaljer som skall ingå och vilka som är tillägg utöver det ursprungliga kontraktet, eftersom kunden är ovan med att definiiera mjukvaruspecifikationer.
Ett annat problem som kan uppkomma i projektet är att tiden för projektet är väldigt kort och därför blir det relativt kritiskt att man snabbt kommer fram med en bra lösning på problemet. I efterhand kan det vara svårt att ändra på denna lösning och göra en helt ny lösning eftersom man helt enkelt inte har tid att göra detta. Att arbeta med prototyper är en sak som tyvärr inte kan användas i detta projektet, fastän det troligen vore det bästa sättet att få kundinteraktion.
3)
Kunden är inte säker på vad han verkligen vill ha och hur systemet borde se ut för att vara användarvänligt, detta skulle i så fall kunna leda till problem i slutändan av projektet om produkten inte visar sig vara tillräckligt användarvänlig, då detta är en av de mest kritiska delarna i projektet för att alla inom TopBike skall acceptera att övergå till detta system. .
Programmerarna på SMEsonline är så pass införstådda i rörliga arbetsmetoder att de inte följer arbetsordningen för plandriven programmering, och därmed skapar problem i projektet. Eftersom arbetsstyrkan är liten och de anställda på företaget är unga nyutbildade programmerare har man troligen använt sig i huvudsak av rörliga metoder i programmeringsprojekt. Detta gör de ovana med att använda plandrivna metoder att det orsakar ännu mera problem att inte använda rörliga metoder.
4)
Om man utgående från ett poldiagram undersöker huruvida det är klokt att använda rörliga metoder så kan man se vissa trender. Om man utgående från den fempoliga diagramsmodellen undersöker detta projekt och börjar med att undersöka hur pass kritiskt systemet bör vara så har det vissa kritiska delar som måste tas i beaktande. Bland annat kommer man att behöva ha redundans på programmet som följd av reglementen angående datasäkerhet. Utöver det kan man anse att så gott som hela affärsverksamheten flyttas över till detta system, så detta leder till att systemet måste vara stabilt.
Angånde polen om storleken på programmeringsstyrkan så kommer den inte att vara särskilt hög i detta projekt som till sin storlek är ganska litet, och detta gör att programmerarna kan använda sig av rörliga metoder.
Dynamiken i projektet kan också anses vara relativt hög, och behovet av att utöka och ändra om systemet kan anses vara befogat i och med att systemet kommer att användas också av kunder vilket gör det viktigt att utseendet är enkelt och överskådligt, men på samma gång fräscht och tilltalande.
Personalen som kommer att använda systemet kommer troligen att vara relativt liten och förhoppningsvis kommer det i programmeringsteamet att finnas relativt stor del av erfarna programmerare som är vana med rörliga metoder och att ändra krav efter behov. Detta är också en delorsak till att det vore mera ändamålsenligt att använda rörliga metoder.
Kulturen på företaget SMEsonline kan anses vara relativt nymodig och ungdomlig, och detta skulle också innebära det lättare att implementera rörliga metoder framom plandrivna metoder i detta projekt.
Med polardiagrammets hjälp har vår grupp kommit fram till att det mest effektiva sättet att arbeta i detta projekt är med hjälp av rörliga metoder. Dock har vårt system vissa kritiska funktioner som man måste vara noggrann med och dessa funktioner skulle man kanske kunna ordna med någon slags form av plandrivna metoder för att säkerställa att funktionerna verkligen fungerar och håller en hög kvalitet.
5)
Det som är viktigt är att systemet är stabilt och därför måste man lära sig om lagstiftningen kring det som behövs för att hålla systemet lagligt. En annan sak som är viktigt med projektet är att man relativt snabbt kommer ut på marknaden med sitt system innan andra skapar konkurrerande system. Därför bör projektet ha en klar rörlig metodik som man arbetar med för att snabbt komma fram med fungerande programvara som kan visa kunden hur det slutgiltiga systemet kommer att se ut.
För att kunna säkerställa att projektet hålls "på rätt köl" borde man i projektgruppen ha med åtminstone en erfaren programmerare som håller koll på hur systemet utvecklas. Annars kan man lätt hamna i en situation att systemet kommer in i ett dödläge där man inte kommer framåt mera utan måste börja om på nytt med att designa systemet och det vore förödande för tidtabellen på projektet.
6)
För att undvika problem med att kunden inte vet vad han behöver bör man i ett tidigt skede underrätta honom om företagets arbetssätt och göra honom uppmärksam på hur han kan styra systemet och definiera det. Detta gör att kunden får mera insyn i systemet och förstår bättre vad det är som han behöver. En annan sak som man kan göra för att ytterligare få information om huruvida det slutgiltiga systemet borde se ut skulle kunna vara att fråga kunden om exempel på användarvänliga system för att därigenom lyckas luska ut vad kunden behöver.
Därtill måste man ständigt hålla klart för sig vilken funktionalitet som förväntas i det slutgiltiga systemet så man har ett mål med projektet och kan avsluta det i tid. Annars finns det en överhängande risk att projektets slutliga version blir "hängande" i luften när tiden tar slut i projektet.